Forum:Multilingual support problems
category:language Thurstan has detected a fault in part of our multilingual support system. I have been using French as default language for Wikia sites for the last few weeks. Pages I have created are now apparently displaying some headings or connecting text in French even to people using English. The key is probably related to , perhaps simply that that has not been used everywhere it should have been. Here's the report that sparked the inquiry: :When I look at the children of Mary Howell (1782-1854) (a page you created), I see "Birth: February 17, 1816 à New Jersey, United States", but when I create pages, I see "in" rather than "à". I think this is a bug in our language support. Thurstan 22:18, September 22, 2010 (UTC) Discussion of solutions is welcome. So as to minimize duplication of work, please report here any investigations and changes. — Robin Patterson (Talk) 00:50, September 23, 2010 (UTC) I think the problem is that is being used where it shouldn't, namely when generating properties: the property is being set based on the user language preference, rather than the page language. The easiest solution is not to have a word that need translation in the properties: just generate "Birth: February 17, 1816, New Jersey, United States". Thurstan 05:36, September 23, 2010 (UTC) Property:Birth date *has type::Date *subproperty of (allows search on) subproperty of::Property:event date Property:Birth year Property:Birth locality Paragraphs of explanation with mention of string or language, then: SMW characteristics: *Type:}}}|year=date|if-bce=boolean|number}} *subproperty of (allows search on) }}} }}| *subproperty of (allows search on) subproperty of::Property: } }}} |} (and so on, with no mention of language or string Property:Event date *Type:has type::Date Form:Children It's long! Plenty of mention of , with these parameters: *fm-form-children intro *fm-person article insert *fm-edit children facts *fm-warning form buttons *fm-family information *fm-family group *fm-joined_with *fm-unknown *fm-married question *fm-children *fm-sources *fm-notes *fm-family information more Then a lot of repetition, for each group. Form:Person ... } } } ''' } } } |type=textarea }}} } |default=|?sex=}}|| } } } } }} } } } } } } } } Strings fm list These are the only ones starting with a preposition (except for several that are clearly instructions rather than labels: *fm147 fm-tmpl-translation-04 into *fm149 fm-in (location) in *fm213 fm-with With That fm149 may be our target. Somehow. — Robin Patterson (Talk) 10:13, September 23, 2010 (UTC) Details The problem properties are Birth place and Death place. * yields " ". (appearing as "in Glen Innes..." for me — Robin Patterson (Talk) 03:27, September 24, 2010 (UTC)) * yields " ". (appearing as "à Kingston..." for me — Robin Patterson (Talk) 03:27, September 24, 2010 (UTC)) These properties are set in , which uses (which evalutes to " ", "in" for me). Since it is a prefix (rather than a separator), we can't just replace it with a comma, since that doesn't work when we only have a place and no date. Perhaps the template could use a variant of which uses the page language only, and ignores the user language. Another possibility is to remove the preposition from these properties, and supply it when needed when displaying the page. This properly separates property values from display issues, and is my preferred solution. Thurstan 23:40, September 23, 2010 (UTC) :Thank you for finding where "in" is relevantly used. I've noted the bug on its talk page. I can't see anything against your preferred solution, but (with my low level of understanding of code) that means little. A third opinion would be helpful. It seems the same bug appears on tree pages, e.g. the tree for Mary's child, where I see "Mary Howell (1782-1854) Birth: à Kingston, Somerset County, New Jersey, United States, 19 February 1782. Death: à Caldwell, Essex County, ...". But I presume it doesn't affect , where I see "Mary Howell was born 19 February 1782 in Kingston, ...". — Robin Patterson (Talk) 03:27, September 24, 2010 (UTC) Since the bug is due to violating the design principle of "separation of concerns", specifically "separation of presentation and content", I don't think there is another option to fix it. As you have noticed, calls which uses the properties birth blurb and death blurb, which will also have to change. As noted in its documentation, does not do translation. Thurstan 06:09, September 24, 2010 (UTC)